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Abstract 


This paper presents a new concept in compiler correctness: instead of proving 
that the compiler performs all of its transformations correctly, the compiler generates 
a proof that the transformed program correctly implements the input program. A 
simple proof checker can then verify that the program was compiled correctly. We 
call a compiler that produces such proofs a credible compiler, because it produces 
verifiable evidence that it is operating correctly. 

Compiler optimizations usually consist of two steps — an analysis step determines 
if it is legal to apply the optimization, and a transformation step applies the optimiza- 
tion to generate a transformed program that computes the same result as the original 
program. Our approach supports this two-step structure. It provides a logic that the 
compiler can use to prove that its program analysis results are correct, and a logic 
that the compiler can use to prove that the transformed program correctly simulates 
the original program. These logics are defined for a standard program representation, 
control flow graphs. This report defines these logics and proves that they are sound 
with respect to a standard operational semantics. It also presents detailed examples 
that demonstrate how a compiler can use the logics to prove the correctness of several 
standard optimizations. 

We believe that credible compilation has the potential to revolutionize the way 
compilers are built and used. Specifically, they will allow programmers to quickly 
determine if the compiler compiled their program correctly, help developers find and 
eliminate bugs in compiler passes, allow large groups of mutually untrusting people 
to collaborate productively on the same compiler, increase the speed with which 
compilers are developed and released, and make it possible to aggressively upgrade 
large, stable compiler systems without fear of inadvertantly introducing undetected 
errors. 


1 Introduction 


Today, compilers are black boxes. ‘The programmer gives the compiler a program, and the 
compiler spits out an inscrutable bunch of bits. Until he or she runs the program, the 
programmer has no idea if the compiler has compiled the program correctly. Even running 


the program offers no guarantees — compiler errors may show up only for certain inputs. 
So the programmer must simply trust the compiler. 

We propose a fundamental shift in the relationship between the compiler and the pro- 
grammer. Every time the compiler transforms the program, it generates a proof that the 
transformed program produces the same result as the original program. When the com- 
piler finishes, the programmer can use a simple proof checker to verify that the program 
was compiled correctly. We call a compiler that generates these proofs a credible compiler, 
because it produces verifiable evidence that it is operating correctly. 

We believe that credible compilation has the potential to revolutionize the way com- 
pilers are built and used. Instead of having to accept whatever the compiler generates on 
blind faith, programmers will be able to verify that the compiler compiled their program 
correctly. Credible compilers will also help developers find and eliminate bugs in compiler 
passes, allow large groups of mutually untrusting people to collaborate productively on 
the same compiler, make it possible to aggressively upgrade large, stable systems without 
fear of inadvertantly introducing undetected errors, promote the use of compilers that are 
customized for specific application domains, shrink the length of the compiler development 
cycle by making it practical to use buggy compilers, and make the use of compilers that 
do not produce correctness proofs a successful basis for product liability claims. 
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Figure 2: Credible Compilation 


Figures 1 and 2 graphically illustrate the difference between traditional compilation and 
credible compilation. A traditional compiler generates a compiled program and nothing 
else. A credible compiler, on the other hand, also generates a proof that the compiled 
program correctly implements the original program. A proof checker can then take the 
original program, the proof, and the compiled program, and check if the proof is correct. 
If so, the compilation is verified and the compiled program is guaranteed to correctly 
implement the original program. If the proof does not check, the compilation is not verified 
and all bets are off. 

This paper introduces the basic techniques required to build credible compilers for 


standard programming languages such as C and Java. The organization is as follows. 
Section 2 presents an example that illustrates the basic concepts of standard invariants, 
which are used to prove that program analysis results are correct, and simulation invariants, 
which are used to prove that a transformed program generates the same result as the 
original program. Section 3 presents the technical core of the paper: the logics used to 
prove standard invariants and simulation invariants, and the proofs that these logics are 
sound. Section 4 presents a running example that shows how to generate correctness 
proofs for several standard transformations. Section 5 discusses some anomalies associated 
with proving that loops terminate, Section 6 discusses issues related to code generation, 
and Section 7 discusses related work. Section 8 discusses the potential impact of credible 
compilation. We present our conclusions in Section 9. 


2 Example 


In this section we present an example that explains how a credible compiler can prove that 
it performed a translation correctly. Figure 3 presents the example program represented 
as a control flow graph. The program contains several assignment nodes; for example the 
node 5:1 i+2+y at label 5 assigns the value of the expression 7+ 2+ y to the variable 
i. There is also a conditional branch node 4: bri < 24 . Control flows from this node 
through its outgoing left edge to the assignment node at label 5 if 7 < 24, otherwise control 
flows through the right edge to the exit node at label 7. 


1:2<0 1:2<0 
| | 
2:n£<1 2:n£<1 
| | 
B:y2 3B:y2 
gee Ze 
4: bri< 24 | 4: bri< 24 | 


VAS 


S:tc1+4et+y 7: exit 


6:g2*7t 


Lo > X 


57:4¢14+3 7 2 exit 


6:ge2*t 


; ae Figure 4: Program After Constant Propa- 
Pig: Ure mal Progen alien and Coat Folding 

Figure 4 presents the program after constant propagation and constant folding. The 
compiler has replaced the node 5:2+-7+2+y at label 5 with the node 5:1¢ i1+3. The 
goal is to prove that this particular transformation on this particular program preserves the 
semantics of the original program. The goal is not to prove that the compiler will always 
transform an arbitrary program correctly. 

To perform this optimization, the compiler did two things: 


e Analysis: The compiler determined that x is always 1 and y is always 2 at the 
program point before node 5. So, x + y is always 3 at this program point. 


e Transformation: The compiler used the analysis information to transform the pro- 
gram so that generates the same result while (hopefully) executing in less time or 
space or consuming less power. In our example, the compiler simplifies the expression 
x+y to 3. 


Our approach to proving optimizations correct supports this basic two-step structure. 
The compiler first proves that the analysis is correct, then uses the analysis results to 
prove that the original and transformed programs generate the same result. Here is how 
this approach works in our example. 


2.1 Proving Analysis Results Correct 


Many years ago, Floyd came up with a technique for proving properties of programs [4]. 
This technique was generalized and extended, and eventually came to be understood as a 
logic whose proof rules are derived from the structure of the program [2]. The basic idea 
is to assert a set of properties about the relationships between variables at different points 
in the program, then use the logic to prove that the properties always hold. If so, each 
property is called an invariant, because it is always true when the flow of control reaches 
the corresponding point in the program. 

In our example, the key invariant is that at the point just before the program exe- 
cutes node 5, it is always true that 7 = 1 and y = 2. We represent this invariant as 
(c =1Ay=2)5. Section 3.3 presents a logic that the compiler can use to prove such in- 
variants. In effect, this logic allows the compiler to construct proofs by induction on the 
length of the partial executions of the program. 

In our example, the simplest way for the compiler to generate a proof of (x = 1 A y = 2)5 
is for it to generate a set of invariants that represent the analysis results, then use the logic 
to prove that all of the invariants hold. Here is the set of invariants in our example: 


Conceptually, the compiler proves this set of invariants by tracing execution paths. 
The proof is by induction on the structure of the partial executions of the program. For 
each invariant, the compiler first assumes that the invariants at all preceding nodes in the 
control flow graph are true. It then traces the execution through each preceding node 
to verify the invariant at the next node. We next present an outline of the proofs for 
several key invariants. The compiler can use the logic presented in Section 3.3 to produce 
machine-verifiable versions of these proofs. 


e (x =1)3 because the only preceding node, node 2, sets x to lL. 


e To prove (x =1A y= 2)4, first assume (x = 1)3 and (x = 1A y= 2)6. Then con- 
sider the two preceding nodes, nodes 3 and 6. Because (7 = 1)3 and 3 sets y to 2, 
(c =1Ay=2)4. Because (x = 1A y = 2)6 and node 6 does not affect the value of 
either x or y, (cs =1LAy = 2)4. 


In this proof we have assumed that the compiler generates an invariant at almost all of 
the nodes in the program. More traditional approaches use fewer invariants, typically one 
invariant per loop, then produce proofs that trace paths consisting of multiple nodes. The 
logic presented in Section 3.3 supports both styles of proofs. 


2.2 Proving Transformations Correct 


When a compiler transforms a program, there are typically some externally observable 
effects that it must preserve. A standard requirement, for example, is that the compiler 
must preserve the input/output relation of the program. In our framework, we assume 
that the compiler is operating on a compilation unit such as procedure or method, and 
that there are externally observable variables such as global variables or object instance 
variables. The compiler must preserve the final values of these variables. All other variables 
are either parameters or local variables, and the compiler is free to do whatever it wants 
to with these variables so long as it preserves the final values of the observable variables. 
The compiler may also assume that the initial values of the observable variables and the 
parameters are the same in both cases. 

In our example, the only requirement is that the transformation must preserve the final 
value of the variable g. The compiler proves this property by proving a simulation corre- 
spondence between the original and transformed programs. To present the correspondence, 
we must be able to refer, in the same context, to variables and node labels from the two 
programs. We adopt the convention that all entities from the original program P will have 
a subscript of P, while all entities from the transformed program T' will have a subscript 
of T. So ip refers to the variable 7 in the original program, while 77 refers to the variable 7 
in the transformed program. 

In our example, the compiler proves that the transformed program simulates the original 
program in the following sense: for every execution of the original program P that reaches 
the final node 7p, there exists an execution of the transformed program T that reaches the 
final node 77 such that gp at 7p = gr at 77. We call such a correspondence a simulation 
invariant, and write it as (gp)7p & (gr)7r. In Section 3.4 we present a logic that the 
compiler can use to prove simulation invariants. 

The compiler typically generates a set of simulation invariants, then uses the logic to 
construct a proof of the correctness of all of the simulation invariants. The proof is by 
induction on the length of the partial executions of the original program. We next outline 
how the compiler can use this approach to prove (gp)7p > (gr)7r. First, the compiler is 
given that (gp)lp > (gr)lr — in other words, the values of gp and gr are the same at the 
start of the two programs. The compiler then generates the following simulation invariants: 


° ((gp,ip))2p & (gr, tr))2r 


¢ ((gp,ip))3p & (gr, tr))3r 


° ((gp,ip))4p & (gr, tr) )4r 


© ((9p,tp))5p & (gr, tr))5r 
° ((gp,ip))6p & (gr, tr) )6r 
© (9p)Tp > (gr)Tr 


The key simulation invariants are (gp)7p > (gr)7r, ((gp,ip))6p > ((gr,ir))6r and 
((gp,ip))4p > ((gr,tr))4r. We next outline the proofs of these two invariants. The com- 
piler can use the logic presented in Section 3.4 to produce machine-verifiable versions of 
these proofs. 


e To prove (gp)7p> (gr) 7r, first assume that ((gp,ip))4p > ((gr,ir))4r. For each path 
to 7p in P, we must find a corresponding path in T to 7p such that the values of gp 
and gr are the same in both paths. The only path to 7p goes from 4p to 7p when 
ip > 24. The corresponding path in T goes from 47 to 7p when ip > 24. Because 
(gp, tp))4p & ((gr,ir))4r, control flows from 47 to 77 whenever control flows from 
4p to 7p. The simulation invariant ((gp,ip))4p > ((gr,ir))4r also implies that the 
values of gp and gr are the same in both cases. 


e To prove ((gp,ip))6p > ((gr,ir))6r, assume ((gp,ip))5p & ((gr,ir))5r. The only 
path to 6p goes from 5p to 6p, with ip at 6p = ip at 5p + xp at 5p + yp at Sp. The 
analysis proofs showed that xp at 5p +yp at 5p = 3, so ip at 6p = ip at 5p +3. The 
corresponding path in T’ goes from 57 to 67, with 77 at 67 = ip at 5p + 3. 


The assumed simulation invariant ((gp,ip))5p > ((gr, ir))5r allows us verify a corre- 
spondence between the values of ip at 6p and ip at 6p; namely that they are equal. 
Because 5p does not change gp and 57 does not change gr, gp at 6p and gr at 6p 
have the same value. 


e To prove ((gp,ip))4p & ((gr,ir))4r, first assume ((gp,ip))3p > ((gr,ir))3r and 
((gp,ip))6p & ((gr,ir))6r. There are two paths to 4p: 


— Control flows from 3p to 4p. The corresponding path in T is from 37 to 47, 
so we can apply the assumed simulation invariant ((gp,ip))3p & ((gr,ir))3r to 
derive gp at 4p = gr at 47 and 7p at 4p = 77 at 4r. 


— Control flows from 6p to 4p, with gp at 4p = 2 * ip at 6p. The corresponding 
path in T is from 67 to 47, with gp at 47 = 2 * ip at 67. We can apply the 
assumed simulation invariant ((gp,ip))6p > ((gr,ir))6r to derive 2 * ip at 6p 
= 2 «ip at 6p. Since 6p does not change ip and 67 does not change 77, we can 
derive gp at 4p = gr at 47 and 7p at 4p = 77 at 4p. 


3 Logical Foundations 


In this section we present the logical foundations of credible compilation. We formally 
define a program representation based on control flow graphs and define an operational 
semantics for this representation. We present the logic used to prove standard invariants 
and prove that this logic is sound. We also present the logic used to prove simulation 
invariants and prove that this logic is sound. 


3.1 Program Representation 


We propose that compiler passes use a common intermediate representation based on con- 
trol flow graphs. It is possible, of course, to write translators between intermediate represen- 
tations so that passes that use specialized or merely different intermediate representations 
can participate. In this section we define a simple intermediate representation that we use 
to present the major ideas and concepts in the remainder of the paper. We expect that a 
practical implementation would require a more elaborate intermediate representation. 

We start with expressions e and conditions c. For simplicity we assume the program 
computes on integer values; we denote the set of integers by z € Z. We also assume disjoint 
sets of local variables | € LZ and externally observable variables o € O; the set of variables 
v € V = LUO is the union of these two sets. Variables have integer values and expressions 
evaluate to integers. The following abstract syntax defines the set of expressions e. 


e n= Z|Vie+ ele Sele « ele/ele%e| Sel 
true|falsele = ele £ ele > ele > ele < ele < elrele Acle V ele > ele Se 


In some cases, we interpret an expression as a condition c whose value is true or false. 
We adopt the C convention that a condition is true if its value is not zero, and false if its 
value is zero. In the expression grammar above, true is 1 and false is 0. 

Each control flow graph is composed of a set of nodes. Each node has its own label; 
these labels are used to determine the flow of control between nodes. Each node is one of 
the following types: 


e Assignment: An assignment node s : v ¢ e t has its label s, a variable v, an 
expression e and a label t. When the node executes, it evaluates e and assigns the 
value to v. Execution continues at the node whose label is ¢. 


e Conditional Branch: A conditional branch node s : br c t, tg has its label s, a 
condition ¢ and two labels t; and tg. When the node executes, it evaluates c. If 
c is true, execution continues at the node whose label is tj. Otherwise, execution 
continues at the node whose label is te. 


e Nop: A nop node s : nop t has its label s and another label t. When the node 
executes, execution continues at the node whose label is ft. 


e Exit: The exit node s, : exit is the last node in the graph. 


There is a unique entry node with label s9 and a unique exit node with label s,. We require 
that there be a path from the entry node to the exit node, and that no two distinct nodes 
have the same label. 

We use the notation that s : v < e t is true if there exists an assignment node with 
label s, variable v, expression e and label t in the control flow graph, and false otherwise. 
Also, s : br € t, ty is true if there is a conditional branch node in the control flow graph 
with label s, condition c, and labels t; and ft, in the program, and false otherwise, and 
similarly for nop and exit nodes. We use this notation to define the set of predecessors of 
a node in the control flow graph: 


Definition 1 Given a label t, the set of predecessors of t is the set of all labels of nodes 
from which control may flow directly to t: 
pred(t) = {s]s: vc et}U{s|s: nopt}U{s]s: brett} U {s]s: bret’ t} 


We require that the entry node so have no predecessors, i.e., pred(so) = 9. Also note 
that the exit node has no successors, i.e. for all s, s; ¢ pred(s). 


3.2 Operational Semantics 


We next present a simple operational semantics for control flow graphs. The semantics 
uses configurations (s,m), which consist of the label s of the next node to execute and 
a memory m:V — Z that maps each variable to its value. We start by extending the 
domain of the memory function m to constants and expressions as shown in Figure 5. 


m(z) = 

m(ey + pve m(ei) + m(e2) 
me, Se2) = m(e1) Sm(eg) 
m(e, * €2) = m(e,) * M(ez) 
m(e1/e2) = m(e1)/m(e2) 
m(e1%e2) = m(e1)%m/(e2) 
m(<e) = =m(e) 

m(true) = true 

m(false) = false 

m(e, = €2) = 
m( 
m( 
m( 
m( 
m( 
m( 
m( 
m( 
m( 


m(e,) = m(e2) 
€1 > €2) = m(e1) > m(e2) 
€1 > €2) = m(e1) > meg) 
€1 < €2) = m(e1) < m(e2) 
€1 < €2) = m(e1) < meg) 
ne) = am(e) 

C1 A C2) = m(c1) A m(c2) 
C1 V C2) = m(c1) V m(c2) 
C1 > C2 et C2) 


Figure 5: Extending m to Constants and Expressions 


The operational semantics is defined using a transition function — which maps each 
configuration (s,m) to its successor configuration (s’,m/’). The successor configuration is 
obtained by executing the node at label s in the context of memory m. Figure 6 presents 
the rules that define the transition function. In the initial memory mo, local variables have 
value 0 and observable variables have arbitrary values. 

We use the operational semantics to define the concept of a partial execution of a control 
flow graph. A partial execution starts at the entry node in the graph, and executes part of 
the computation. 


Definition 2 A partial execution of a control flow graph is a sequence of configurations 


s:veet 
“(s,m) > (t,mlv+> m(e)])_ op-assign (1) 


Gm) > Em — . 
Gm) > (tm) eee, - 
8: bre ti te, amc) op-brfalse (4) 


(s,m) — (te, m) 
Figure 6: Operational Semantics 


(50,0) +++ > (Sn,™Mn) in which each configuration (si41,Mi41) is the successor of the 
preceding configuration (s;,mj;) in the sequence. 


3.3. Standard Invariants 


We next present the logic that the compiler can use to construct proofs that its analysis 
results are correct. The logic consists of a set of proof rules; these rules are a version of 
the standard Floyd-Hoare proof rules adapted for control flow graphs. The rules operate 
on several types of invariants: 


e (i)s: the condition 7 is always true at the program point before the execution of the 
node whose label is s. 


e s(i)t: the condition 7 is always true at the program point before the execution of the 
node whose label is t, if control flowed directly to t from s. 


e (i)s-t: the condition 7 is always true at the program point before the execution of 
the node whose label is s, if control will flow next to t. 


The proof rules assume a set J of invariants; we require that invariants of the form s(i)t 
or (i)s-¢t do not appear in J. Figure 7 presents the rules. We assume the existence 
of a logic for proving standard relationships between integers such as z < z+ 1 and 
GARY SSS Oye. 


3.3.1 Proof Trees 


Proofs consist of a tree whose nodes are rule uses. One rule use is a child of another rule use 
if the consequent of the first rule use is an antecedent of the second rule use. Contrary to 
computer science custom (but consistent with nature), proof trees are customarily drawn 
with each parent node below its children. There is a partial order defined on the rule uses 
— a first use precedes a second use if the second use appears on the path from the first use 
to the root. The last rule in the proof tree is therefore the root. 
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Figure 7: Proof Rules for Standard Invariants 
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Figure 10: Abbreviated Proof Tree for J (a =1Ay = 2)4 


Figure 8 presents the proof tree for J F 6(c = 1A y = 2)4. To save space on the page, 
from now on we present proof trees in abbreviated form. This form omits details such as 
antecedents that are references to nodes in the control flow graph or trivial implications. 
Figure 9 presents the abbreviated proof tree for J+ 6(2 = 1A y = 2)4. Figure 10 presents 
the abbreviated proof tree for J (2 = 1A y= 2)4. In these proof trees, 


LaHaye S24 1 Aa Doe Sa TA S26} 


3.3.2 Soundess of Proof Rules for Standard Invariants 


We next prove a key soundness theorem: that if there exists a proof of all of the invariants 
in J, then the invariants correctly reflect the relationships during the execution of the 
program. We first prove a lemma used in the theorem, then prove the theorem itself. 


Lemma 1 Assume for all (i)s € I, IF (i)s. Also assume a proof of IF (i)s-t and a 
partial execution (8 9,™mo) + +--+ > (s,m) such that IF (i')s implies m(i’) is true. Then 
m(i) is true. 


Proof: We do a case analysis of the last rule in the proof of JF (i)s-t. Rules 10 and 11 
are the only rules of the correct form. 


e The last rule in the proof is rule 10. In this case we have a proof of J + (i)s, and by 
assumption m(i) is true. 


e The last rule in the proof is rule 11 with (i’)s € I and 7’ = i, which implies m(i’) > 
m(i). By assumption (i’)s € J implies J + (i')s, which implies m(i’) is true. We can 
therefore simplify m(i’) > m(i) to m(¢) is true. 


tT 


Theorem 1 Assume for all standard invariants (i)s € I, IF (i)s. Then I + (i)t and 
(59,0) > --- — (t,m) implies m(i) is true. 


Proof: Induction on the length of the partial execution (59, mo) 4 --- — (t,m). 

Base: In this case t = s9, which implies pred(t) = @. The proof is therefore a use of rule 
12 with 7, which implies m(7) is true. 

Induction: In this case the partial execution is at least one step long, so we can write it 
as (9,79) — ---(s,m’) — (t,m) for some s € pred(t). We do a case analysis of the last 
rule in the proof of J (i)t. Rules 12 and 5 are the only rules of the correct form. 


e The last rule is 12 with 7, which implies m(i) is true. 


e The last rule is 5. Because s € pred(t), there is a proof of JF s(i)t. We do a case 
analysis of the last rule in this proof. Rules 6, 7, 8 and 9 are the only rules of the 
correct form. 


— The last rule is 6, with s : nop t. Then m = m’ and we have a proof of IF (i)s-t. 
By Lemma 1, m(i) is true. 

— The last rule is 7, with s:v < et. Then m = m’[v + m'(e)] and we have a 
proof of IF (i[e/v])s-t. By Lemma 1, m’(i[e/v]) is true, which we can rewrite 
as m'[v +> m’(e)|(i) is true, then simplify to m(7) is true. 

— The last rule is 8, with s : br ct t’, m’ = m, and m’(c) is true, and there is a 
proof of I (c => i)s-t. By Lemma 1, m’(c => 1) is true, which we can simplify 
to m'(c) > m'(i), then to m(2) is true. 

— The last rule is 9, with s : br ct’ t, m’ = m, and m’‘(c) is false, and there is 
a proof of IF (nc > i)s-t. By Lemma 1, m’(-c => 7) is true, which we can 
simplify to m'(ac) => m’(i), then to m(2) is true. 


3.4 Simulation Invariants 


We next present the logic that the compiler uses to prove simulation invariants between 
two programs P and T. We assume that P and T are two disjoint control flow graphs with 
entry nodes s} and sé and initial memories mj and mj, respectively. We also assume sets 
{ol,...,o, } and {of ,...,0/} of externally observable variables and that corresponding 
externally observable variables have the same values at the start of the program — i.e., 
mé (oP) = mb (of) for 1 <i<n. 

For purposes of presentation, we adopt the convention that P is the original program 
and T is the transformed program, although of course the logic imposes no constraint on 
the origin of the two programs. Simulation invariants consist of two partial simulation 
invariants that together express a simulation relationship between the partial executions 
of the programs. For example, (ci, e1)s1 > (c2,€2)S2 is true if for all partial executions 
of P that reach s, with the condition c, true, there exists a partial execution of T that 
reaches s2 with co true such that e; = e2. Like the logic for standard invariants presented 
in Section 3.3, the logic for simulation invariants uses multiple labels to express how the 
flow of control affects relationships between the two programs. 


Definition 3 A partial simulation invariant p has the form (c,e)t, s(c,e)t or (c,e)s +t, 
where c is a condition and e 1s an expression. 
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We adopt the convention that a partial simulation invariant of the form (e)t, s(e)t, or 
(e)s-t denotes, respectively, (true, e)t, s(true, e)t, or (true, e)s- t. 


Definition 4 A simulation invariant has the form p, > p2, where p, and p2 are partial 
simulation invariants. 


Figures 11, 12, and 13 present the proof rules. Each proof propagates the partial 
simulation invariants against the flow of control through the two programs. Eventually, 
the partial simulation invariants reach program points where it is possible to terminate the 
proof by applying rule 13 or rule 14. The rules in Figure 12 propagate the partial simulation 
invariant from the original program; the rules in Figure 13 propagate the partial simulation 
invariant from the transformed program. 

The proof rules all refer to a set J of invariants. In general, this set will contain 
both standard invariants of the form (c)s and simulation invariants of the form (c1, e;)s1 > 
(C2, €2)S2. We require that it does not contain simulation invariants whose partial simulation 
invariants are of the form s(c,e)t or (c,e)s-t. 

The proof rules illustrate a key difference between the treatment of the original and 
transformed programs. Rule 15 requires that the simulation invariant hold on all paths 
in the original program. Rule 22 requires only that the simulation invariant hold on one 
path in the transformed program. This difference reflects the asymmetry in the implicit 
quantifiers of the simulation invariant, which is true if for all paths in the original program, 
there exists a path in the transformed program that satisfies the appropriate conditions. 


T T = 
(01,.--,0, ) Aa >a@ANe =e 


(07',+-+,0n) = 
TF (ey, €1)89 & (C2, €2) 89. 


base (13) 


TF (is) 81,1 F (iz) 2, (Ch, €) 81 & (Ch, 5) 52 € I, 
HAAS QuAkAaNe, =e => (Ae = 2) induction (14) 
IF (C1, €1) $1 “tb (C2, €2) 82 


Figure 11: Simulation Invariant Base and Induction Proof Rules 


3.4.1 The Simulation Condition 


To prove that the transformed program simulates the original program, the compiler gen- 
erates a set of invariants J and a proof of each invariant. We require one of the invariants 
to state that the transformed program preserves the values of the externally observable 
variables. We formalize this concepts as follows: 


Definition 5 A transformed program T simulates an original program P if there exists a 
set of invariants I such that 


e for all standard invariants (i)s € I, IF (i)s, 


e for all simulation invariants (ci, e1) 81 & (C2, €2)s2 € I, TF (c1,€1) 51 & (C2, €2)52, and 
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pred(t) 4 0,Vs € pred(t). + s(c,e)t > p 


It (c,e)t> p 


s:nopt,l- (c,e)s-tbp 


I 


s:vueeét It (cle’/ul,ele’/u])s-t&> p 


I 


F s(c,e)t > p 


F s(c,e)t > p 


s:bre ti ta,Ik (cAc,e)s-t > p 
It s(c,e)ti & p 


s: bre ty ta, TF (cA 7c, e)s-te > p 
I' s(c,e)te > p 


TF (a,e)s-top,Ie(a,e)s-te pcS>aVe 


It (c,e)s-t>p 


Te (c,e)s > p 
It (ce)s-t>p 


orig-pred 


orig-nop 


Orig-assign 


orig-brtrue 


orig-brfalse 


OTtg-Case 


orig-step 


Figure 12: Proof Rules for the Original Program P 


ds € pred(t). J pb s(c,e)t 


IF pe (cet 


s:nopt,l F p> (c,e)s 


I 


+ p> s(c,e)t 


s:veeét, IE pe (cle’/v, ele’/v])s 


I 


t p> s{c,e)t 


s:bre t,t, pe (cAc,e)s 
IF pp s(c,e)ty 


s:bre tt, pe (cAn7c,e)s 
IF pe s(c,e)te 


trans-pred 


trans-nop 


trans-assign 


trans-brtrue 


trans-brfalse 


Figure 13: Proof Rules for the Transformed Program T 
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(15) 


(16) 


(17) 


(18) 


(19) 


(20) 


(21) 


(25) 


(26) 


e the simulation invariant ((o;,...,01))s, & ((ot,...,02))si € I, where {of ,..., 01 
and {o{,...,0,} are sets of corresponding externally observable variables, s’ is the 


exit node in P, and si is the exit node in T. 


3.4.2 Standard Form Proofs of Simulation Invariants 


We next introduce the concept of a standard form for proofs of simulation invariants. This 
standard form simplifies the presentation of the soundness proofs. A standard form proof 
has the following structure. Each leaf in the proof tree is a use of rule 13 or 14. Along 
each path in the proof tree from the leaves towards the root, the proof first uses rules 22 
through 26 to propagate the partial simulation invariant from the transformed program 
through the program. Note that in this phase of the proof tree, each rule use has exactly 
one child. Next, uses of rules 15 through 21 appear on the path. These uses propagate the 
partial simulation invariant from the original program P. Because the proof must verify 
the simulation invariant for all paths in the original program, uses of rule 5 will have one 
child for each predecessor of the corresponding node in the control flow graph. 


Definition 6 A proof of a simulation invariant is in standard form if all uses of rules 22 
through 26 precede all uses of rules 15 through 21. 


Theorem 2 /f I+ p,> po, then there exists a proof of I p,& pe that is in standard form. 


Proof: Induction on the depth of the proof of IF p, > po. 

Base: The proof is a use of rule 13 or 14. By definition of standard form, the proof is in 
standard form. 

Induction Step: We assume that the proof is in standard form except for the last rule, 
then find an equivalent proof in standard form. We do a case analysis of the last rule. 


e The last rule is one of 15 through 21. By definition of standard form, the proof is in 
standard form. 


e The last rule is one of 22 through 26. The proof is in standard form unless the 
next-to-last rule is one of 15 through 21. We do a case analysis on the next-to-last 
rule. 


— The next-to-last rule is 21 or one of 16 through 19. Then the proof is of the 


form: 
1 
IF pe pm 
TE pb pb 
IF p> pe 
We can switch the last two rules of the proof to obtain the following equivalent 
proof: 
1 
IF p> py 
IF p> pe 
IF p> pe 
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By the induction hypothesis, we can obtain an equivalent standard form proof 
w’ for the proof 


ae le ow 
Th p> py 
IF p po 


The following proof is then in standard form: 
qr! 


IF p, & peo 


The next-to-last rule is 15. Then the proof is of the form: 


Ty Tn, 
Tepe py +++ Th php p 
TE p> ph 
IF p> po 


We can push the last rule of the proof through rule 15 to convert the proof to 
an equivalent proof of the form: 


Ty Tn 
ITE pre ps IE pid py 
TE pl> py «++ TE p? > po 

IF p, & pe 


By the induction hypothesis, we can obtain a standard form proof 7; for each of 
the proofs 


as 
TE pi > p 
IF pi & po 


then use these standard form proofs to construct the following standard form 
proof of IF p, > pa: 
meen 


IF pi & pe 
The next-to-last rule is 20. Then the proof is of the form: 


Ty 1) 
ITF (q,e)s-tep' ITE ia,e)s-thp c>aVeg 
Tt (c,e)s-tD>p 


We can push the last rule of the proof through rule 20 to convert the proof to 
an equivalent proof of the form: 


TY 1) 
ITF (q,e)s-t>p' Ik (a,e)s-tb p! 
ITF (q,e)s-tep IK (a,e)s-thp cS aVeg 
It (c,e)s-t>p 
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By the induction hypothesis, we can obtain standard form proofs 7} and 1, for 
the two proofs 
Ty uD) 
ITF (q,e)s-top’ Ik (ce, e)s-tb p 
TF (q,e)s-t>p TK (ea,e)s-thp 


then use these standard form proofs to construct the following standard form 
proof of I+ p; > pao: 
T, 1, C3 OVCQ 


IF py > po 


3.4.3. Soundness of Proof Rules for Simulation Invariants 


We next show that the proof rules for simulation invariants are sound. We first prove two 
lemmas, then the theorem. 


Lemma 2 Assume that for all (i)s € I, I+ (i)s and for all (ci, e1)51 & (co, e2)52 € T, 
ITF (ce, €1)51 & (C2, €2)S2. Assume a standard form proof of I p& (ce, €2)82 whose last 
rule is one of 18, 14 or 22, where p= (cq, €1)51 or p = (41, €1)51-t. Also assume a partial 
execution (s),m)) + --+ — (s1,m1) such that mi(c,) is true. If p = (c1,e1)81-t, also 
assume that I + (c,e’)s; > (c,e)s and mj(c’) is true implies that there exists a partial 
execution (s,,mi) + --- + (s,m) such that m(c) is true and mi(e’) = m(e). Then 
there exists a partial execution (s),m4) + --- — (82,mz) such that m2(c2) is true and 
my,(e€1) = Mo(e2). 


Proof: Induction on the length of the proof of I + p> (cg, €2) 52. 
Base: The proof consists of a use of either rule 13 or rule 14. We do a case analysis of this 
rule. 


e The proof is a use of rule 13 with (o/',...,07) = (of ,...,01) = cg Ae, = eg. Then 
mi, = més and m2 = mj, which implies mi(e1) = me(e2) and mi(ci) => me(c2). 


Because m (cz) is true, m2(c2) is true. 


e The proof is a use of rule 14 with p = (c1,e1)51-t, DF (ii)s1, TF (iz) sa, (ce), e}) 51 & 
(ch, e5)s2 EL, Ac => cand ty AigANG Ae = eb > (@ Ae1 = €2). By assumption 
mi(c1) is true, by Theorem 1 m4(i1) is true, so 7; Ac, = c, implies m,(c)) is true. 
By assumption, (cj, e))51 > (ch,e4)52 € I implies that J + (cc, e))s1 & (ch, e4) 52, so 
there exists a partial execution (s4,mj) 4 ---— (s,m) such that m(c4) is true and 
mi(e,) = m(es). By Theorem 1 m(i,) is true. Let mg = m. Then i; Aig Aci A 
ey, = & => (C2 Ae1 = €2) implies mi(i1) A ma(t2) A miler) A miley) = me(eh) => 
(m2(c2) A mi(e1) = me(e2)), which can be simplified to obtain me2(c2) is true and 
m1(e1) = Me(e2). 


Induction: We do a case analysis of the last rule of the proof. Because the proof is at 
least two rules deep, the last rule cannot be rule 13 or 14. So the last rule must be 22. In 
this case there is standard form proof of I + p> s(co, €2)S2. We do a case analysis of the 
last rule of this proof. Because the proof is in standard form, rules 23, 24, 25, and 26 are 
the only possibilities. 
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e The last rule is 23 with s : nop s9. There is a standard form proof a of I F p> (co, €2)s. 
Consider the last rule in 7. Because this proof can be extended using rule 23, then rule 
22 to astandard form proof of I + p> (cz, €2)s2, the last rule in 7 is not one of rules 15 
through 21. The only other rules that are of the correct form are rules 13, 14, and 22. 
By the induction hypothesis, there exists a partial execution (s},mj) > --- > (s,m) 
such that m(c2) is true and m,(e,) = m(e2). We can extend this partial execution 
to a partial execution (s},mj) 3 --- 4 (s,m) + (s2,me2), where mz = m. Then 
Mo(C2) is true and m(e1) = me(e2). 


e The last rule is 24 with s : v © e sg. There is a standard form proof a of JF 
p> (ca[e/v], e2{e/v])s. Consider the last rule in 7. Because this proof can be extended 
using rule 24, then rule 22 to a standard form proof of JF pb (co, e2)s2, the last 
rule in 7 is not one of rules 15 through 21. The only other rules that are of the 
correct form are rules 13, 14, and 22. By the induction hypothesis, there exists a 
partial execution (sf,m) + ---— (s,m) such that m(cy[e/v]) is true and m,(e;) = 
m(eg[e/v]). We can extend this partial execution to a partial execution (s§,mj) > 
+++ —> (s,m) — (s9,M2), where m2 = m|[v +> m(e)]. We can then simplify m(c.[e/v]) 
is true to m[v + m(e)|(c2) is true, then to m2(c2) is true. Similarly, we can simplify 
mi(ei) = m(egle/v]) to mi(e1) = ma(e2). 


e The last rule is rule 25 with s : br c sg t. There is a standard form proof of 
IF pb (co Ac,e2)s whose last rule is 13, 14, or 22. By the induction hypothesis, 
there exists a partial execution (sf,m{j) > --- > (s,m) such that m(c2 Ac) is true 
and m,(e1) = m(e2). Because m(c) is true, we can extend this partial execution to 
a partial execution (s§,mj) > ---— (s,m) — (s2,mz2), where my = m, and obtain 
Mo(C€2) is true and m4(e1) = ma(e2). 


e The last rule is rule 26 with s : br c t sg. There is a standard form proof of 
IF pb (cg A 7c, €2)s whose last rule is 13, 14, or 22. By the induction hypothesis, 
there exists a partial execution (sf,m{é) > --- > (s,m) such that m(c2 A 7c) is true 
and m;(e1) = m(ez). Because m(c) is false, we can extend this partial execution to 
a partial execution (s},m)) > --- > (s,m) — (s2,mz), where mz = m, and obtain 
Mo(C€2) is true and m4(e1) = mo(e2). 


Lemma 3 Assume that for all (i)s € I, IF (i)s and for all (cq, €1)s1 & (C2, €2)52 € I, 
IF (cy, e1)s1 & (2, €2)s2. Assume a standard form proof of IF (c1,e1)s1-t & (co, €2) 82 
and a partial execution (sh,mi) > --- — (s1,m1) such that mi(c1) is true. Also assume 
that I+ (c’,e’)s, > (c,e)s and m,(¢) is true implies that there exists a partial execution 
(s§,m6) +--+: — (s,m) such that m(c) is true and m,(e’) = m(e). Then there exists a 
partial execution (85 ,™mj) +++ —> (82,M2) such that mo(c2) is true and m1(e1) = mo(e2). 


Proof: Consider the proof tree of IF (ci, e1)s1 -t > (co, e2)s2. Given a path in this tree 
from the root to a leaf, we can start at the root and compute the number of consecutive 
uses of rule 20 until the first use of a different rule. We call this number the case analysis 
number of the path. If, for example, the last rule in the proof is not a use of rule 20, then 
the root is not a use of rule 20 and, for all paths, the case analysis number is zero. The 
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proof is by induction on the maximum over all paths from the root to a leaf of the case 
analysis number of the path. 

Base: In this case the last rule of the proof is not 20. The only other rules that are of the 
correct form are rules 14, 22, and 21. We do a case analysis on the last rule of the proof: 


e The last rule is 14 or 22. By Lemma 2, there exists a partial execution (s},mé) > 
+++ —>» ($9, M2) such that mo(c2) is true and mj(e1) = mo(e2). 


e The last rule is 21, with J F (c¢,e1)s1 > (c2,€2)s2. Then by assumption, there 
exists a partial execution (s},m)) — --- + (s2,mz2) such that me(c2) is true and 
mi(e1) = M2(e€2). 


Induction: Assume that the proof has maximum case analysis number of k, where k 
is at least one, and the lemma holds for all proofs with maximum case analysis number 
less than k. In this case the last rule of the proof is 20 with c, > cj V c?, and proofs of 
I+ (ch, e1)81 -t & (co, €2) 82, I+ (cf, e1) 81 -t & (co, €2)82. Note that these proofs have a 
maximum case analysis number less than k. If we can show that either m,(c}) is true or 
mz(c7) is true, we can apply the induction hypothesis to one of the proofs. 

Note that c, = cj Vc? implies mi(c1) => mi(ct) Vmi(c7). Because m1(c1) is true, either 
mi(ct) is true or m1(c?) is true. Then by the induction hypothesis, there exists a partial 
execution (sf,mé) > ---— (s2,mz) such that mo(c2) is true and m,(e,) = mo(e2). 


Theorem 3 Assume that for all (i)s € I, IF (i)s and for all (cy, €1) 51 & (C2, €2) $2 € I, 
TF (cy, €1)51 & (C2, €2)82. Then for all standard form proofs of I + (c1, €1)s1 > (co, €2) 82 and 
for all partial executions (sj,,mé) 4 ---—> (s1,m1) such that m1(c1) is true, there exists a 
partial execution (s¢,mé) > --- > (s2,m2) such that mo(c2) is true and mi(e1) = m2(e2). 


Proof: Induction on the length of the partial execution (s{,m i) 3 ---— (s1,m1). 
Base: If the length is 0, then s; = s} and pred(s,;) = @. We do a case analysis of the last 
rule of the proof of IF (c,e1)s1 > (C2, €2)S2. The only rules that are of the correct form 
are rules 13, 15, and 22. Because pred(s,) = Q, rule 15 cannot be the last rule. 


e The last rule is 13 or 22. Then by Lemma 2, there exists a partial execution 
(sh, ) 4 --+— (82,mz) such that me(c2) is true and m;(e1) = ma(e2). 


Induction: In this case the partial execution of P is at least one step long, so we can 
write it as (s4,m4) > --- > (s,m) — (s1,™m1). We do a case analysis of the last rule of 
the proof of IF (c, €1)51 & (C2, €2)S9. The only rules that are of the correct form are rules 
13, 15, and 22. 


e The last rule is 13 or 22. By Lemma 2, there exists a partial execution (s},mj) > 
-++—> ($9, M2) such that mo(c2) is true and mj(e1) = ma(e2). 


e The last rule is 15. Because s € pred(s;), there is a standard form proof of J + 
8(C1, €1) 81 & (C2, €2)S2. We do a case analysis of the last rule in this proof. Because 
the proof is in standard form, 22 is not the last rule. The only other rules that are 
of the correct form are 16, 17, 18, and 19. 
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— The last rule is 16, with s : nop s;. Then m,; = m. By assumption mj(c;) 
is true, which implies that m(c,) is true. There is also a standard form proof 
of IF (ci, e1)s + $1 & (C2, €2)52. By Lemma 3, there exists a partial execution 
(si,m4) + +++ — (s2,m2) such that mo(c2) is true and m(e1) = me2(e2), which 
implies that m1(e1) = m2(e2). 


— The last rule is 17, with s:v < e s;. Then m,; = m[v > m(e)]. By assumption 
my(c,) is true, which implies that m(c,[e/v]) is true. There is also a standard 
form proof of IF (c[e/v], e:[e/v])s - $1 & (C2, €2) 52. By Lemma 3, there exists 
a partial execution (s$,m{) 4 --- — (s2,me2) such that me(c2) is true and 
m(e,[e/v]) = me(e2), which we can simplify to mi(e1) = me(e2). 


— The last rule is 18, with s : br c s; t. Then m; = m and m(c) is true. By 
assumption m;(c1) is true, which implies that m(c; Ac) is true. There is also 
a standard form proof of IF (c, Ac, e1)s - $1 & (C2, €2)S2. By Lemma 3, there 
exists a partial execution (s},mé) 3 --- — (s9,mz) such that mo(c2) is true 
and m1(e1) = mo(e2). 


— The last rule is 19, with s : br c t s;. Then m, = m and m(c) is false. By 
assumption m,(c1) is true, which implies that m(c; A ac) is true. There is also 
a standard form proof of IF (ce; A ac, e1)5- $1 & (C2, €2)s2. By Lemma 3, there 
exists a partial execution (sj,m)) — --- — (s2,m2) such that mo2(c2) is true 
and mj (e1) = mo(e2). 


4 Optimization Schemas 


We next present examples that illustrate how to prove the correctness of a variety of 
standard optimizations. Our goal is to establish a general schema for each optimization. 
The compiler would then use the schema to produce a correctness proof that goes along 
with each optimization. 


4.1 Dead Assignment Elimination 


The compiler can eliminate an assignment to a local variable if that variable is not used after 
the assignment. The proof schema is relatively simple: the compiler simply generates sim- 
luation invariants that assert the equality of corresponding live variables at corresponding 
points in the program. Figures 14 and 15 present an example that we use to illustrate the 
schema. This example continues the example introduced in Section 2. Figure 16 presents 
the invariants that the compiler generates for this example. 

Note that the set J of invariants contains no standard invariants. In general, dead 
assignment elimination requires only simulation invariants. The proofs of these invariants 
are simple; the only complication is the need to skip over dead assignments. Figure 17, 
which contains the proof tree for ((gp,ip))4p & ((gr, ir))4r, illustrates this situation. 
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4: bri< 24 | 


aaa 


5:4414+3 7 2 exit 


6:ge 2x4 


Figure 14: Program P Before Dead Assign- Figure 15: Program T’ After Dead Assign- 
ment Elimination ment Elimination 


T= {((gp,ip))4p & (gr, tr)) 41, (ip)dp & (ir) Sr, (ip) 6p & (ir) 6r, (9p) Tp > (gr) Tr} 


Figure 16: Invariants for Dead Assignment Elimination 


(gp) = (gr) = (gr, 0) = (gr, 0) 
_IF ((gp,0))1e & ((9r,0))1r_ 


IF ((gp,tp))2p & (gr, ir))4r (ip) 6p & (ir) 6r € I, 
IF ((gp,tp))2p : 3p > ((gr, ir))4r ip = iv => Q * ip, ip) = (2 * ir, ir) 
IF 2r((gp, ip))3p > (gr, ir))4r IF ((2 * OP, ip))6p -4p D> ((2 * ir, ir))6r 


Ib ((gp,tp))3p > (gr, tr) )4r Ib ((2 * ip,ip))6p < 4p > 6r (gr, tr))4r 
ITF ((gp,tp))3p-4p > (gr, ir))4r TE (2 «ip, ip))6p- 4p > (gr, ir))4r 
I+ 3p((gp,ip)) 4p & (gr, tr))4r I+ 6p((gp,ip)) 4p & (gr, ir))4r 
Te ((gp,tp))4p > ((9r,tr))4r 


Figure 17: Proof Tree for I+ ((gp,ip))4p > ((gr,ir))4r 


au 


4.2 Branch Movement 


Our next optimization moves a conditional branch from the top of a loop to the bottom. 
The optimization is legal if the loop always executes at least once. This optimization is 
different from all the other optimizations we have discussed so far in that it changes the 
control flow. Figure 18 presents the program before branch movement; Figure 19 presents 
the program after branch movement. Figure 20 presents the set of invariants that the 
compiler generates for this example. 

Figure 23 presents the proof tree for J + (gp)7p > (gr)7r. One of the paths that the 
proof must consider is the path in the original program P from 1p to 4p to 7p. No execution 
of P, of course, will take this path — the loop always executes at least once, and this path 
corresponds to the loop executing zero times. The fact that this path will never execute 
shows up as a false condition in the partial simulation invariant for P that is propagated 
from 7p back to 1p. The corresponding path in T that is used to prove I + (gp)7p> (gr) Tr 
is the path from 17 through 57, 67, and 47 to 7p. Although the values of gp and gr are not 
the same on the two paths, the fact that the condition in the partial simulation invariant 
from P is false enables the use of rule 13 at the leaf of the proof tree. Figure 21 presents 
the branch of the proof tree for this path. 


om, 1::<0 
) 
A 
4: bri<24 | eee 
L ~“ 6: 9g 2x74 
5:4 it3 7: exit 
—_ 4:bri< 24 
x 
7: exit 


Figure 18: Program P Before Branch Figure 19: Program T After Branch Move- 
Movement ment 


I= {(ip)5p & (ir)5r, (ip) 6p & (ir) 6r, (gp) Tp & (gr) Tr} 


Figure 20: Invariants for Branch Movement 
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0>2433>24Agp=6 
TE (0 > 24, gp) 1p > (3 > 24,6) 1p 
IF (0 > 24, gp) |p > Ir(ir +3 > 24,2 (ir + 3))5r 
IF (0 > 24,gp)1p > (ir +3 > 24,2 x (ir + 3))5r 
IF (0 > 24, gp)|p > Snir > 24,2 ir )6r 
TE 0 > 24, gp) p> (ip > 24,2 ¥ ip 6p 
It (0 > 24, gp) 1p © 6rlir > 24, or) 4r 
It 0 > 24, gp)lp & (ir > 24, gr) 4r 
ITE (0 > 24, gp)1p & 4r(gr)Tr 
It (0 > 24, gp)lp B (gr) ?r 
It (0 > 24, gp)lp- 4p (gr) Tr 
IF lp(tp > 24, 9p)4p & (gr) 7r 


Figure 21: Proof Tree 7 for J / lp(ip > 24, gp)4p & (gr) Tr 


(ip) 6p > (ir)6r € I, ip >24ANip=i7 > (ir > 24A2x*ip = 2 ir) 
TE (ip > 24,2 ¥ip)Op 4p D ip > 24,2 * ip Or 
TE (ip > 24,2 * ip)Op 4p D Orlip > 24, gr 4r 
TF (ip > 24,2 * ip)Op 4p D (ip > 24, gr) 47 
IF (ip > 24,2 * ip)6p -4ppD Ar (gr) Tr 
IF (ip > 24,2 * ip)6p -4p bp (gr) Tr 
It 6p(ip > 24, 9p)4p > (gr)Tr 


Figure 22: Proof Tree 72 for I  6p(ip > 24, gp)4p & (gr) Tr 


TT, 79 
It (ip > 24, gp)4p © (gr) Tr 
I} (ip > 24, 9gp)4p - Tp & (gr) Tr 
It 4p(gp)7p © (gr) Tr 
IF (gp)7p & (gr) tr 


Figure 23: Proof Tree for I+ (gp)7p > (gr)7r 
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4.3 Induction Variable Elimination 


Our next optimization eliminates the induction variable 7 from the loop, replacing it with g. 
The correctness of this transformation depends on the invariant (gp = 2 *ip)4p. Figure 24 
presents the program before induction variable elimination; Figure 25 presents the program 
after induction variable elimination. Figure 26 presents the set of invariants that the 
compiler generates for this example. These invariants characterize the relationship between 
the eliminated induction variable ip from the original program and the variable gr in 
the transformed program. Figure 27 presents the proof tree for J F (2 *ip)4p & (gr) 47; 
Figure 28 presents the proof tree for J+ (gp)7p & (gr)7r. 
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Figure 24: Program P Before Induction Figure 25: Program T After Induction 
Variable Elimination Variable Elimination 


L= {(gp =—2x ip)4p, ie * ip)5p > (gr)5r, (2 * ip)4p > (gr)4r, (gp)Tp > (gr) Tr} 


Figure 26: Invariants for Induction Variable Elimination 
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(2 *ip)5p > (gr)ir € 1,2 *ip = gr => 2 * (ip + 3) = gr+6 
Ib (2 *k (ip + 3))5p ; 6p > (or + 6)5¢r 
IF (2 * (ip + 3))5p : 6p > Sr (gr) 4r 
ITF 5p(2 *ip)6p > (gr)4r 
Ib (2 * ip)6p > (gr) 4r 
Ib (2 * ip)6p -4p bp (gr) 4r 
IF 6p(2 * ip)4p > (gr) 4r 
TE (2 ip)4p B (gr) 4r 


Figure 27: Proof Tree for I (2 *ip)4p > (gr) 4r 


Ib (gp = Dk ip)4p, (2 * ip)4p > (gr) 4r € i, 
gp =2*ipNip > 24A2 ip = gr => (gr > 48 A gp = Qr) 
I+ (ip > 24, gp)4p- Te (gr > 48, or) 4r 
Ib (ip > 24, gp)4p - 7p & Ar{gr) Tr 
IE (ip = 24, gp)4p - Tp B (gr) Tr 
It 4p(gp)Tp & (or) tr 
IF (gp)?p & (gr) tr 


Figure 28: Proof Tree for I+ (gp)7p > (gr)7r 
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4.4 Loop Unrolling 


The next optimization unrolls the loop once. Figure 29 presents the program before loop 
unrolling; Figure 30 presents the program after unrolling the loop. Note that the loop 
unrolling transformation preserves the loop exit test; this test can be eliminated by the 
dead code elimination optimization discussed in Section 4.5. 


l:g0 
a 
l:g+0O ZAG 59220 
L | 
dig+gt+6 3:brg < 48 
| ZA 
| 4: br g < 48 d:g<g+6 
S | 
7: exit 4:brg < 48 
fs 
7: exit 


Figure 29: Program P Before Loop Un- Figure 30: Program T After Loop Un- 
rolling rolling 


IT = {(gp%12 =O0V gp%12 = 6)4p, (gp%12 = 0,9p)5p > (gr)2r, 
(gp%12 = 6, gp)4p & (gr) 37, (gp%12 = 6, gp)5p & (gr) 57, 
(gp%12 = 0, 9p)4p & (gr)4r, (gp) Tp > (gp)TP} 


Figure 31: Invariants for Loop Unrolling 


Figure 31 presents the set of invariants that the compiler generates for this example. 
Note that, unlike the simulation invariants in previous examples, these simulation invariants 
have conditions. The conditions are used to separate different executions of the same node 
in the original program. Some of the time, the execution at node 4p corresponds to the 
execution at node 47, and other times to the execution at node 37. ‘The conditions in 
the simulation invariants identify when, in the execution of the original program, each 
correspondence holds. For example, when gp%12 = 0, the execution at 4p corresponds to 
the execution at 47; when gp%12 = 6, the execution at 4p corresponds to the execution at 
3p. 

Figure 34 presents the proof tree for J + (gp)7p & (gr)7r. The key part of the proof 
is the use of the case analysis rule, rule 20. This rule is a key component of correctness 
proofs for transformations, like loop unrolling, that replicate code. 
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(gp%12 = 0, gp)4p © (gr)4r € I, gp%12 = 0A gp > 48 => gp%12 = 0, 
gp/l2 =0A gp > 48 A gp = Gr = (gr = 48 A gp = Gr) 
IF (gp%12 =0A gp > 48, gp)4p - 7p & (gr = 48, gr) 4r 
IF (gp%12 =OAgp> 48, gp)4p -TpP Ar( gr) Tr 
IF (gp%12 =0A gp > 48, 9p)4p- 7p > (gr) Tr 


Figure 32: Proof Tree 7, for IF (gp%12 =0 A gp > 48, gp)4p - Tp > (gr) Tr 


Ib (gp%12 =O0V gp%12 = 6) 4p, (gp%12 = 6, gp) 4p > (gr) 3r € as 
(9p%12 =0V gp%12 = 6) A (gp%12 £0 A gp > 48) > gp%12 = 6, 
(gp%12 =0V gp%12 = 6) A (gp%12 £0 A gp > 48) A gp = gr = (gr = 48 gp = Gr) 
IE (gp%12 #0 A gp > 48, 9p)4p - 7p & (gr = 48, gr) 3r 
IF (gp%12 a OAgp > 48, gp)4p -TpP 3r( gr) Tr 
IF (gp%12 #0 A gp > 48, gp)4p - Tp > (gr) Tr 


Figure 33: Proof Tree 72 for IF (gp%12 40 A gp > 48, gp)4p - Tp > (gr) Tr 


Tm 72 gp > 48 = (ge%12 =0A gp > 48) V (gp%12 #0 A gp > 48) 
IE (gp = 48, 9p) 4p + Tp & (gr) Tr 
Ib 4p(gp)7p & (gr) Tr 
IF (gp)7p & (gr) Tr 


Figure 34: Proof Tree for I+ (gp)7p > (gr)7r 
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4.5 Dead Code Elimination 


Our next optimization is dead code elimination. We continue with our example by elim- 
inating the branch in the middle of the loop at node 3. Figure 35 presents the program 
before the branch is eliminated. The key property that allows the compiler to remove the 
branch is that g%12 =6 Ag < 48 at 3, which implies that g < 48 at 3. In other words, the 
condition in the branch is always true. Figure 36 presents the program after the branch 
is eliminated. Figure 37 presents the set of invariants that the compiler generates for this 
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Figure 35: Program P Before Dead Code Figure 36: Program T’ After Dead Code 
Elimination Elimination 


a {(gp%12 =OAgp< 48)2p, (gp%12 =6Agp< 48)3 p, (gp%12 =6Agp< 48)5p, 
(gp/12 =0A gp < 48)4p, (gp)2p > (gp)2p, (9p)dp > (gp) 5p, 
(gp)3p > (gp)5p, (gp)4p © (gp)4p, (gp) Tp > (gp)TP} 


Figure 37: Invariants for Dead Code Elimination 


Figure 40 presents the proof tree for J + (ip)7p > (ir)7r. One of the paths that the 
proof must consider is the potential loop exit in the original program P from 3p to 7p; 
Figure 39 presents the branch of the proof tree that corresponds to this path. In fact, 
the loop always exits from 4p, not 3p. This fact shows up because the conjunction of the 
standard invariant (gp%12 = 6 A gp < 48)3p with the condition gp > 48 from the partial 
simulation invariant for P at 3p is false. The corresponding path in T' that is used to prove 
IF (ip)7p © (ir)7r is the path from 57 to 47 to 77. Although the values of gp and gr 
are not the same on the two paths, the fact that the conjunction described above is false 
enables the use of rule 14 at the leaf of the proof tree. 
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(gp)4p > (gr) 4r € I, 
gp = gr \gp > 48 = (gr > 48 gp = 97) 
I+ (gp > 48, 9p)4p- Tp > (gr > 48, gr) 4r 
I+ (gp = 48, 9p)4p - Tp 4r(gr) Tr 
IF (gp = 48, 9p)4p + Tp & (gr) Tr 
It 4p(gp) 7p 2 (gr) Tr 


Figure 38: Proof Tree 7, for I+ 4p(gp)7p & (gr)7r 


IF (gp%12 =6A gp < 48)3p, (gp)3p & (gr)dr € I, 
gp%12=6 A gp < 48 A gp > 48 A gp = gr = (gr +6 = 48 A gp = Gr + 8) 
Ib (gp = 48, 9p)3p - Tp Db (gr +6 = 48, gr + 6) 57 
I+ (gp > 48, 9p)3p- Tp > Sp(gr > 48, gr) 4r 
I+ (gp > 48, 9P)3p- Tp > (gr > 48, gr) 4r 
It (gp = 48, 9p)3p - Tp & Ap (gr) Tr 
It (gp = 48, gp)3p- Tp & (gr) tr 
IF 3p(gp)7p > (gr)?r 


Figure 39: Proof Tree 72 for I+ 3p(gp)7p & (gr)7r 


TN, To 
I+ (gp) 7p & (gr)Tr 


Figure 40: Proof Tree for I+ (gp)7p > (gr)7r 
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5 Termination Anomalies 


Throughout the paper so far, we have required that the transformed program simulate the 
original program in the sense that for every execution in the original program that reaches 
the exit node, there exists an execution in the transformed program that reaches the exit 
node such that the values of the observable variables are the same. 

There is, however, an anomaly associated with this notion of simulation. What happens 
if the original program contains an infinite loop? Then any program simulates the original 
program. One can imagine that programmers might like to have stronger guarantees. 

One option is to require also that the original program simulate the transformed pro- 
gram. If the two programs simulate each other, the transformed program terminates if 
and only if the original program terminates. And if they terminate, they terminate with 
identical values in corresponding observable values. We anticipate that this will be a good 
solution in practice. 

There is, however, a potential anomaly associated with this approach. The logics for 
proving simulation invariants are based on notions of partial correctness. For some pro- 
grams, it is impossible to use the logic to prove that they simulate each other, even if they 
both terminate with the same result. Consider the two programs in Figures 41 and 42 that 
compute g = 48. Using the logic presented in Section 3.4, it is not possible to prove that the 
iterative program in Figure 41 simulates the program in Figure 42. Roughly speaking, the 
problem is that the logic cannot prove that the loop in the iterative program terminates. 


l:gO 
A 
d:g—gt6 l:g+ 48 
l | 
| 4: br g < 48 2: exit 
Ss 
7: exit 


Figure 41: Iterative Program to Compute Figure 42: Closed Form Program to Com- 
g = 48 pute g = 48 


We do not anticipate that this anomaly will prove to be a problem in practice, because 
the overwhelming majority of compiler transformations do not eliminate or introduce loops. 
If it does turn out to be a problem in practice, the solution is to augment the logic so that 
it can prove that loops terminate. 


6 Code Generation 


In principle, we believe that it is possible to produce a proof that the final object code 
correctly implements the original program. For engineering reasons, however, we designed 
the proof system to work with a standard intermediate format based on control flow graphs. 
The parser, which produces the initial control flow graph, and the code generator, which 
generates object code from the final control flow graph, are therefore potential sources 
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of uncaught errors. We believe it should be straightforward, for reasonable languages, to 
produce a standard parser that is not a serious source of errors. It is not so obvious how 
the code generator can be made simple enough to be reliable. 

Our goal is make the step from the final control flow graph to the generated code be 
as small as possible. Ideally, each node in the control flow graph would correspond to 
a single instruction in the generated code. ‘To achieve this goal, it must be possible to 
express the result of complicated, machine-specific code generation algorithms (such as 
register allocation and instruction selection) using control flow graphs. After the compiler 
applies these algorithms, the final control flow graph would be structured in a stylized 
way appropriate for the target architecture. The code generator for the target architecture 
would accept such a control flow graph as input and use a simple translation algorithm to 
produce the final object code. 

With this approach, we anticipate that code generators can be made approximately as 
simple as proof checkers. We therefore anticipate that it will be possible to build standard 
code generators with an acceptable level of reliability for most users. However, we would 
once again like to emphasize that it should be possible to build a framework in which the 
compilation is checked from source code to object code. 

In the following two sections, we first present an approach for a simple RISC instruction 
set, then discuss an approach for more complicated instruction sets. 


6.1 A Simple RISC Instruction Set 


For a simple RISC instruction set, the key idea is to introduce special variables that the 
code generator interprets as registers. The control flow graph is then transformed so that 
each node corresponds to a single instruction in the generated code. We first consider 
assignment nodes. 


e If the destination variable is a register variable, the source expression must be one of 
the following: 


— A non-register variable. In this case the node corresponds to a load instruction. 
— A constant. In this case the node corresponds to a load immediate instruction. 


— A single arithmetic operation with register variable operands. In this case the 
node corresponds to an arithmetic instruction that operates on the two source 
registers to produce a value that is written into the destination register. 


— A single arithmetic operation with one register variable operand and one con- 
stant operand. In this case the node corresponds to an arithmetic instruction 
that operates on one source register and an immediate constant to produce a 
value that is written into the destination register. 


e If the destination variable of an assignment node is a non-register variable, the source 
expression must consist of a register variable, and the node corresponds to a store 
instruction. 


It is possible to convert assignment nodes with arbitrary expressions to this form. The first 
step is to flatten the expression by introducing temporary variables to hold the intermediate 
values computed by the expression. Additional assignment nodes transfer these values to 
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the new temporary variables. ‘The second step is to use a register allocation algorithm to 
transform the control flow graph to fit the form described above. 

We next consider conditional branch nodes. If the condition is the constant true or false, 
the node corresponds to an unconditional branch instruction. Otherwise, the condition 
must compare a register variable with zero so that the instruction corresponds either to a 
branch if zero instruction or a branch if not zero instruction. 


6.2 More Complex Instruction Sets 


Many processors offer more complex instructions that, in effect, do multiple things in a 
single cycle. In the ARM instruction set, for example, the execution of each instruction 
may be predicated on several condition codes. ARM instructions can therefore be modeled 
as consisting of a conditional branch plus the other operations in the instruction. The x86 
instruction set has instructions that assign values to several registers. 

We believe the correct approach for these more complex instruction sets is to let the 
compiler writer extend the possible types of nodes in the control flow graph. The semantics 
of each new type of node would be given in terms of the base nodes in standard control 
flow graphs. We illustrate this approach with an example. 

For instruction sets with condition codes, the programmer would define a new variable 
for each condition code and new assignment nodes that set the condition codes appro- 
priately. The semantics of each new node would be given as a small control flow graph 
that performed the assignment, tested the appropriate conditions, and set the appropriate 
condition code variables. If the instruction set also has predicated execution, the control 
flow graph would use conditional branch nodes to check the appropriate condition codes 
before performing the instruction. 

Each new type of node would come with proof rules automatically derived from its 
underlying control flow graph. The proof checker could therefore verify proofs on control 
flow graphs that include these types of nodes. The code generator would require the 
preceding phases of the compiler to produce a control flow graph that contained only those 
types of nodes that translate directly into a single instruction on the target architecture. 
With this approach, all complex code generation algorithms could operate on control flow 
graphs, with their results checked for correctness. 


7 Related Work 


Most existing research on compiler correctness has focused on techniques that deliver a 
compiler guaranteed to operate correctly on every input program [5]; we call such a com- 
piler a totally correct compiler. A credible compiler, on the other hand, is not necessarily 
guaranteed to operate correctly on all programs — it merely produces a proof that it has 
operated correctly on the current program. 

In the absence of other differences, one would clearly prefer a totally correct compiler 
to a credible compiler. After all, the credible compiler may fail to compile some programs 
correctly, while the totally correct compiler will always work. But the totally correct 
compiler approach imposes a significant pragmatic drawback: it requires the source code of 
the compiler, rather than its output, to be proved correct. So programmers must express 
the compiler in a way that is amenable to these correctness proofs. In practice this invasive 
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constraint has restricted the compiler to a limited set of source languages and compiler 
algorithms. Although the concept of a totally correct compiler has been around for many 
years, there are, to our knowledge, no totally correct compilers that produce close to 
production-quality code for realistic programming languages. Credible compilation offers 
the compiler developer much more freedom. The compiler can be developed in any language 
using any methodology and perform arbitrary transformations. The only constraint is that 
the compiler produce a proof that its result is correct. 

The concept of credible compilers has also arisen in the context of compiling synchronous 
languages [3, 7]. Our approach, while philosophically similar, is technically much different. 
It is designed for standard imperative languages and therefore uses drastically different 
techniques for deriving and expressing the correctness proofs. 

We often are asked the question “How is your approach different from proof-carrying 
code [6]?”! In our view, credible compilers and proof-carrying code are orthogonal concepts. 
Proof-carrying code is used to prove properties of one program, typically the compiled 
program. Credible compilers establish a correspondence between two programs: an original 
program and a compiled program. Given a safe programming language, a credible compiler 
will produce guarantees that are stronger than those provided by typical applications of 
proof-carrying code. So, for example, if the source language is type safe and a credible 
compiler produces a proof that the compiled program correctly implements the original 
program, then the compiled program is also type safe. 

But proof-carrying code can, in principle, be used to prove properties that are not 
visible in the semantics of the language. For example, one might use proof-carrying code 
to prove that a program does not execute a sequence of instructions that may damage the 
hardware. Because most languages simply do not deal with the kinds of concepts required 
to prove such a property as a correspondence between two programs, credible compilation 
is not particularly relevant to these kinds of problems. 


8 Impact of Credible Compilation 


We next discuss the potential impact of credible compilation. We consider five areas: 
debugging compilers, increasing the flexibility of compiler development, just-in-time com- 
pilers, concept of an open compiler, and the relationship of credible compilation to building 
custom compilers. 


8.1 Debugging Compilers 


Compilers are notoriously difficult to build and debug. In a large compiler, a surprising 
part of the difficulty is simply recognizing incorrectly generated code. The current state of 
the art is to generate code after a set of passes, then test that the generated code produces 
the same result as the original code. Once a piece of incorrect code is found, the developer 
must spend time tracing the bug back through layers of passes to the original source. 
Requiring the compiler to generate a proof for each transformation will dramatically 
simplify this process. As soon as a pass operates incorrectly, the developer will immediately 
be directed to the incorrect code. Bugs can be found and eliminated as soon as they occur. 


'Proof-carrying code is code augmented with a proof that the code satisfies safety properties such as 
type safety or the absence of array bounds violations. 
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8.2 Flexible Compiler Development 


It is difficult, if not impossible, to eliminate all of the bugs in a large software system 
such as a compiler. Over time, the system tends to stabilize around a relatively reliable 
software base as it is incrementally debugged. The price of this stability is that people 
become extremely reluctant to change the software, either to add features or even to fix 
relatively minor bugs, for fear of inadvertantly introducing new bugs. At some point the 
system becomes obsolete because the developers are unable to upgrade it quickly enough 
for it to stay relevant. 

Credible compilation, combined with the standard organization of the compiler as a 
sequence of passes, promises to make it possible to continually introduce new, unreliable 
code into a mature compiler without compromising functionality or reliability. Consider 
the following scenario. Working under deadline pressure, a compiler developer has come up 
a prototype implementation of a complex transformation. This transformation is of great 
interest because it dramatically improves the performance of several SPEC benchmarks. 
But because the developer cut corners to get the implementation out quickly, it is unreliable. 
With credible compilation, this unreliability is not a problem at all — the transformation is 
introduced into the production compiler as another pass, with the compiler driver checking 
the correctness proof and discarding the results if it didn’t work. The compiler operates 
as reliably as it did before the introduction of the new pass, but when the pass works, it 
generates much better code. 

It is well known that the effort required to make a compiler work on all conceivable 
inputs is much greater than the effort required to make the compiler work on all likely 
inputs. Credible compilation makes it possible to build the entire compiler as a sequence of 
passes that work only for common or important cases. Because developers would be under 
no pressure to make passes work on all cases, each pass could be hacked together quickly 
with little testing and no complicated code to handle exceptional cases. The result is that 
the compiler would be much easier and cheaper to build and much easier to target for good 
performance on specific programs. 

A final extrapolation is to build speculative transformations. The idea is that the 
compiler simply omits the analysis required to determine if the transformation is legal. It 
does the transformation anyway and generates a proof that the transformation is correct. 
This proof is valid, of course, only if the transformation is correct. The proof checker filters 
out invalid transformations and keeps the rest. 

This approach shifts work from the developer to the proof checker. The proof checker 
does the analysis required to determine if the transformation is legal, and the developer 
can focus on the transformation and the proof generation, not on writing the analysis code. 


8.3. Just-In-Time Compilers 


The increased network interconnectivity resulting from the deployment of the Internet has 
enabled and promoted a new way to distribute software. Instead of compiling to native 
machine code that will run only on one machine, the source program is compiled to a 
portable byte code. An interpreter executes the byte code. 

The problem is that the interpreted byte code runs much slower than native code. The 
proposed solution is to use a just-in-time compiler to generate native code either when the 
byte code arrives or dynamically as it runs. Dynamic compilation also has the advantage 
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that it can use dynamically collected profiling information to drive the compilation process. 

Note, however, that the just-in-time compiler is another complex, potentially erroneous 
software component that can affect the correct execution of the program. If a compiler 
generates native code, the only subsystems that can change the semantics of the native 
code binary during normal operation are the loader, dynamic linker, operating system 
and hardware, all of which are relatively static systems. An organization that is shipping 
software can generate a binary and test it extensively on the kind of systems that its 
customers will use. If the customer finds an error, the organization can investigate the 
problem by running the program on a roughly equivalent system. 

But with dynamic compilation, the compiled code constantly changes in a way that may 
be very difficult to reproduce. If the dynamic compiler incorrectly compiles the program, it 
may be extremely difficult to reproduce the conditions that caused it to fail. This additional 
complexity in the compilation approach makes it more difficult to build a reliable compiler. 
It also makes it difficult to assign blame for any failure. When an error shows up, it could 
be either the compiler or the application. The organizations that built each product tend 
to blame each other for the error, and neither one is motivated to work hard to find and 
fix the problem. The end result is that the total system stays broken. 

Credible compilation can eliminate this problem. If the dynamic compiler emits a 
proof that it executed correctly, the run-time system can check the proof before accepting 
the generated code. All incorrect code would be filtered out before it caused a problem. 
This approach restores the reliability properties of distributing native code binaries while 
supporting the convenience and flexibility of dynamic compilation and the distribution of 
software in portable byte-code format. 


8.4 An Open Compiler 


We believe that credible compilers will change the social context in which compilers are 
built. Before a developer can safely integrate a pass into the compiler, there must be some 
evidence that pass will work. But there is currently no way to verify the correctness of the 
pass. Developers are therefore typically reduced to relying on the reputation of the person 
that produced the pass, rather than on the trustworthiness of the code itself. In practice, 
this means that the entire compiler is typically built by a small, cohesive group of people in 
a single organization. The compiler is closed in the sense that these people must coordinate 
any contribution to the compiler. 

Credible compilation eliminates the need for developers to trust each other. Anyone 
can take any pass, integrate into their compiler, and use it. If a pass operates incorrectly, 
it is immediately apparent, and the compiler can discard the transformation. There is no 
need to trust anyone. The compiler is now open and anyone can contribute. Instead of 
relying on a small group of people in one organization, the effort, energy, and intelligence 
of every compiler developer in the world can be productively applied to the development 
of one compiler. 

The keys to making this vision a reality are a standard intermediate representation, 
logics for expressing the proofs, and a verifier that checks the proofs. The representation 
must be expressive and support the range of program representations required for both 
high level and low level analyses and transformations. Ideally, the representation would be 
extensible, with developers able to augment the system with new constructs and new axioms 
that characterize these constructs. The verifier would be a standard piece of software. We 


35 


expect several independent verifiers to emerge that would be used by most programmers; 
paranoid programmers can build their own verifier. It might even be possible to do a formal 
correctness proof of the verifier. 

Once this standard infrastructure is in place, we can leverage the Internet to create a 
compiler development community. One could imagine, for example, a compiler development 
web portal with code transformation passes, front ends, and verifiers. Anyone can download 
a transformation; anyone can use any of the transformations without fear of obtaining an 
incorrect result. Each developer can construct his or her own custom compiler by stringing 
together a sequence of optimization passes from this web site. One could even imagine 
an intellectual property market emerging, as developers license passes or charge electronic 
cash for each use of a pass. In fact, future compilers may consist of a set of transformations 
distributed across multiple web sites, with the program (and its correctness proofs) flowing 
through the sites as it is optimized. 


8.5 Custom Compilers 


Compilers are traditionally thought of and built as general-purpose systems that should 
be able to compile any program given to them. As a consequence, they tend to contain 
analyses and transformations that are of general utility and almost always applicable. Any 
extra components would slow the compiler down and increase the complexity. 

The problem with this situation is that general techniques tend to do relatively pedes- 
trian things to the program. For specific classes of programs, more specialized analyses and 
transformations would make a huge difference [9, 8, 1]. But because they are not generally 
useful, they don’t make it into widely used compilers. 

We believe that credible compilation can make it possible to develop lots of different 
custom compilers that have been specialized for specific classes of applications. The idea 
is to make a set of credible passes available, then allow the compiler builder to combine 
them in arbitrary ways. Very specialized passes could be included without threatening the 
stability of the compiler. One could easily imagine a range of compilers quickly developed 
for each class of applications. 

It would even be possible extrapolate this idea to include optimistic transformations. In 
some cases, it is difficult to do the analysis required to perform a specific transformation. In 
this case, the compiler could simply omit the analysis, do the transformation, and generate 
a proof that would be correct if the analysis would have succeeded. If the transformation 
is incorrect, it will be filtered out by the compiler driver. Otherwise, the transformation 
goes through. 

This example of optimistic transformations illustrates a somewhat paradoxical property 
of credible compilation. Even though credible compilation will make it much easier to 
develop correct compilers, it also makes it practical to release much buggier compilers. In 
fact, as described below, it may change the reliability expectations for compilers. 

Programmers currently expect that the compiler will work correctly for every program 
that they give it. And you can see that something very close to this level of reliability is 
required if the compiler fails silently when it fails — it is very difficult for programmers to 
build a system if there is a reasonable probability that a given error can be caused by the 
compiler and not the application. 

But credible compilation completely changes the situation. If the programmer can 
determine whether or not the the compiler operated correctly before testing the program, 
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the development process can tolerate a compiler that occasionally fails. 

In this scenario, the task of the compiler developer changes completely. He or she is 
no longer responsible for delivering a program that works almost all of the time. It is 
enough to deliver a system whose failures do not significantly hamper the development of 
the system. There is little need to make very uncommon cases work correctly, especially if 
there are known work-arounds. The result is that compiler developers can be much more 
aggressive — the length of the develoment cycle will shrink and new techniques will be 
incorporated into production compilers much more quickly. 


9 Conclusions 


Most research on compiler correctness has focused on obtaining a compiler that is guaran- 
teed to generate correct code for every input program. This paper presents a less ambitious, 
but hopefully much more practical approach: require the compiler to generate a proof that 
the generated code correctly implements the input program. Credible compilation, as we 
call this approach, gives the compiler developer maximum flexibility, helps developers find 
compiler bugs, and eliminates the need to trust the developers of compiler passes. 

This paper presents logics that a compiler can use to prove that its transformations are 
correct, and provides examples that illustrate how the proofs would work for several stan- 
dard transformations. The logics support the standard two-phase approach to optmization: 
there is a logic that the compiler can use to prove that its analysis results are correct, and a 
logic that the compiler can use to prove that the transformed program correctly implements 
the original program. 

This paper marks the beginning of the research. Our future plans include integrat- 
ing techniques for handling pointers, dynamic memory allocation, and dynamic method 
dispatch into the framework. We also intend to implement a credible compiler. This im- 
plementation will provide valuable insight into the level of performance achievable with a 
credible compiler and the size of the correctness proofs. 

In a broader context, humans evolved in small groups characterized by deep, lifelong 
personal relationships based on mutual familiarity and trust. But the major changes in 
the organization of human society — agriculture, urbanization, the industrial revolution, 
and telecommunications — have all changed the human experience towards ever more 
ephemeral, anonymous interactions with larger groups of people. A global computer net- 
work and the concommitant rise of a society organized primarily around information will 
accelerate this trend with a vengeance. As people interact increasingly with and through 
networked computers instead of other people, we need a replacement for the trust that 
comes with personal relationships. One possible replacement, at least for relationships 
based primarily on information manipulation, is to augment information with evidence 
that it is in some sense correct. This approach decouples the trustworthiness of the infor- 
mation from its source, eliminating the need to trust the entities with whom one interacts. 
Credible compilers are one concrete example of this principle. 
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